The background description provided herein is for the purpose of generally presenting the context of the disclosure. Unless otherwise indicated herein, the materials described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Security, protection from malicious software, has emerged as a major concern of the computing art. It is expected that processors, e.g., some processors from Intel® Corporation of Santa Clara, Calif., will begin to provide support for isolated/protected execution environments to individual applications (also referred to as application execution enclaves or simply, enclaves). Accesses to the enclave memory areas (or referred to as enclave memory page cache) will be limited to codes resident in the enclaves only. Codes outside the enclave will have no access to enclave memory areas. For Intel® processors, the technology is currently known as SGX (Software Guard Extensions). For further information, see Intel® Software Guard Extensions Programming Reference, dated October, 2014.
It is expected that the isolation supports will include support for designating certain physical memory pages to receive increased security protection, e.g., encryption and integrity protection of its content, making a virtualization of the physical memory page with increased security protection in a virtual machine suitable for allocation as part of enclave memory page caches of application execution enclaves of applications of the virtual machine. For example, SGX will include support for an instruction for designating a physical memory page to receive increased security protection. If such physical memory pages with increased security protection were to be modified by other software beside the codes in application execution enclaves that were allocated the physical memory pages, it would lead to corruption of the physical memory pages. On a subsequent access by the code in the application execution enclave, an integrity error would be detected. And the detection of such integrity error would result in a machine check, leading to a system shutdown.
Such corruptions may also be caused indirectly by the operating system (OS) directing a device that it controls to write to the physical memory pages that have been designated to have higher security. Normally an OS prevents such corruptions of memory pages and the resultant shutdown by managing its translation tables to prevent untrusted software from causing such corruptions. However when such an OS is executing in a virtual machine, the virtual machine manager cannot rely on the guest OS not being malicious and intentionally causing such corruptions. Such corruptions leading to shutdown would cause denial of service to the entire platform as they call for all other virtual machines and the virtual machine manager itself to be shutdown. Thus a virtual machine manager should guard against such corruptions.
In the SGX embodiments, in order to guard against such corruptions, the virtual machine manager (VMM) may virtualize the SGX instructions used to designate physical pages to receive higher security and uses a set of page tables that it controls—the extended page tables (EPT) or the second level page tables—to prevent untrusted software from accessing the memory pages that have been designated to receive increased security protection. In order to prevent an OS from corrupting pages using devices it controls, the VMM makes use of an IO memory management unit (IOMMU). This IOMMU may reference the page tables provided by the VMM to determine the set of physical pages that a given device is allowed to access. Processors generally cache the virtual address to physical address translations in a translation lookaside buffer or TLB to avoid walking page tables on each access. The IOMMU generally cache the VM-physical page/address to host-physical page/address translations as obtained from the page tables created by the VMM in an input/output (I/O) translation lookaside buffer or IO TLB to avoid walking page tables on each access. Thus when an SGX instruction is used to designate a memory page to receive higher security, the VMM may update its EPT to deny access to this page from untrusted software i.e. software executing outside of an enclave. However at the time of this designation there might already be a translation to that page in the TLB and/or the IO TLB, thus the TLB and/or the IO TLB may not observe the restrictions put in place by the EPT.
Thus, to avoid such integrity errors leading to system shutdown, on designation of a physical memory page to receive increased security protection, mappings of any other virtual addresses to the physical memory page (direct mappings or indirect mappings via a virtual machine-physical memory page (also referred to as a guest physical memory page)), would need to be invalidated. In particular, for implementations with the guest OS of a virtual machine maintaining its own translation table with mapping entries to map virtual addresses of a virtual machine to virtual machine-physical memory pages of the virtual machine, the stale mapping entries created by a guest OS' mapping table in the processor TLB or the IO TLB would need to be removed (also referred to as a TLB shootdown for some implementations). However, the amount of overhead incurred for removing such stale mapping entries from TLB of all logical processors where that guest OS may have executed as well as from any I/O TLB whenever a physical memory page is designated to receive increased security protection, which could be frequent, could be significant, and impact performance.